Skip to content

Myanglog

퇴사를 하며 - 1년간의 lesson learned

4 min read

얼마전 1년 조금 넘게 다닌 회사를 그만두겠다는 결정을 했다.

처음으로 ‘어떤 문제를 푸는지’를 보고 입사하게된 회사였다. 다녔던 어떤 회사들보다 더 회사가 풀어내고자 하는 문제에 공감했고, 가치있는 일을 했다고 생각한다. 함께 일한 팀원들도 최고였다. 이 생각은 퇴사를 하는 지금 순간에도 변함없다. 그럼에도 이런저런 요인들에 의해 회사와 나는 다른 길을 가야하는 상황이 왔다고 판단했다.

회사에서 무슨 일을 했는지나 퇴사를 왜 하게되었는지 등의 총체적인 회고보다는 그간 나에게 중요했고 경험적으로 체득한 lesson learned를 생각나는대로 정리해보려고 한다.

목적조직을 경험하며 배운것

입사 후 온보딩 기간을 마치고부터 쭉 목적조직에서 일했다. 기능적으로 개발자들끼리 구성된 팀이 아니라 개발자, 디자이너, PO 등 여러직군들이 하나의 목적을 달성하기 위해 구성되는 팀이었다. 처음이라 시행착오도 겪고 단점도 있었지만 나랑 잘 맞았고 배운 점들도 많았다.

언제나 일의 why를 생각해야한다

작년에 일했던 팀에서 특히 가장 많이 공유되었던 컨센서스였다. 우리가 이 일을 왜 해야하는지 모르면, 고객들도 우리 제품을 쓸 이유가 없다는 것.

아무것도 없는 상태에서부터 아이데이션을 하다보면 별의별 의견들이 다 나온다. 꽤 그럴싸하다 싶은 것, 근사한 기능, 기술적으로 해보고 싶은 것, 등등을 다 제치고 우리가 실제로 ‘이 일이 고객들에게 어떤 가치를 줄 수 있는가 - 그리고 그게 우리 팀의 objective에 기여하는가’였다. 이 단순하고 명확한 기준을 끊임없이 서로에게 상기시키고 의사결정에 녹여낸 덕분에 우리가 했던 크고작은 일들 중에 의미없는 일은 단 하나도 없었다고 생각할 수 있게 됐다.

당연하지만 팀 뿐만 아니라 한명의 개발자로서 일을 할 때에도 why를 생각하는건 너무나 중요했다. 디테일한 구현 방법을 아는 사람으로서 더 효과적으로 목적을 충족시키는 방법을 고민하고 제안하며 일했다. 한번은 단순하고 가벼운 목적에 비해 기술적으로 번잡한 요구사항을 받은 적이 있었는데, PO를 찾아가서 물어보니 기술적으로 잘 몰라서 이렇게 해야하는줄 알았다는 답변을 얻고 요구사항을 함께 수정했다. 개발자가 why를 고민한다는건 단순히 주어진 요구사항대로 api를 만들어내는 사람으로 기능하는 것보다 훨씬 더 팀의 미션과 비즈니스에 기여하는 방향이란 생각을 직접 경험을 하며 강화시킬 수 있었다.

작게 실행해보기

뚜렷하게 답이 없는 문제일수록 이게 잘 working할까? 안하는게 더 낫지 않을까? 등등 더 좋은 결정일지 고민하고 논의하는 시간이 길어지기 쉽다. 그럴때마다 우리는 가설을 세우고, 어떻게하면 작게 쪼개서 가설을 검증해볼 수 있을지를 고민하고, 가설을 확인해보고나서 다음 스텝으로 넘어갔다. 불필요하게 크게 어떤 기능을 추가했다가 전체를 롤백하는 일도 없었다. 최소 scope로 기능을 개발해서 유저들에게 이 기능이 실제로 필요했는지를 확인한 뒤에 점점더 고도화하고 더 임팩트있는 기능으로 이어지게끔 했다.

이 프로세스들은 실험을 검증할 수 있는 데이터 파이프라인과 데이터로 의사결정하는 문화가 자리잡아야 가능했던 일이었다. 이전 회사에서 한번 상위 의사결정자가 밑도끝도 없이 ‘oo을 만들어야합니다’라고 해서 만들고, 기획도 마음대로 바뀌고 스펙도 늘어났을 때의 실무자로서 고통을 느껴봤기에 더 이 문화가 너무나 합리적이고 목표에 빨리 다가갈 수 있는 방법임을 체감했다.

회고하면 나아진다

하나의 sprint/iteration이 끝날때마다(보통은 2주정도) 회고를 했다. Keep/Stop/Try 로 항목을 나눠서 우리가 계속 지켜가야할 것, 문제라고 여겨지는것, 시도해볼만한 것들을 함께 고민했다. 마지막에는 ‘회고의 회고’를 작성해보기도 했다. Try에 적어놓고 끝끝내 시도하지 못한 것들도 종종 있긴 했지만 이 과정을 자주 반복하면서 팀이 일하는 방식이 조금씩 체계화 되고 합이 맞아지는걸 경험했다. ‘회고의 회고’를 쓰다보니 회고 방식도 우리의 상황에 맞게 수정되어갔다. 바쁘게 일을 쳐내다가 회고시간이 다가오면 ‘으악 벌써..’하는 마음으로 회의실로 가지만 막상 회고를 하다보면 이게 꼭 필요한 시간이라는걸 상기하곤 했다.

팀원들이 줄어든 기간에 배운것

완벽하게 좋은/나쁜 설계는 없다

작년에는 팀 내에 백엔드개발자가 항상 나말고 한 분씩 더 계셨다. 실력있는 분들이셔서 새로운 기능이나 해야할 업무에 대해 기술적으로 논의를 하다보면 처음 생각한 것보다 좋은 결론이 나왔다. 그러다 올해부터는 혼자 개발하게 되었는데 처음엔 그 상황이 되게 부담스러웠다. 개발하고 운영해야할 범위도 커지고 걱정이 와르르 몰려오던 어느 날 다른 팀 리더와 이야기하다가 “처음부터 완벽한 설계가 어딨나. 운영하면서 알아가는거다” 라는 말을 듣고 정신을 차렸다.

그래서 실제로 운영하고 예전에 최소스펙으로 만든 기능을 고도화하기도 하면서 느낀건, 함께 고민해서 진짜 최선이라고 믿었던 것이든 혼자서 생각한 것이든 특정 요구사항 앞에서는 고쳐야할 레거시가 되기도 한다는 것이었다. 우리는 미래와 변화되는 비즈니스를 완벽하게 알 수 없으니..

과거의 잘못된 결정으로 도저히 고도화가 힘들땐 구조를 조금씩 바꾸고 마이그레이션하는 것으로 해결하면 되긴 했다. 비용이 큰 삽질이지만 직접 안좋은 코드를 짜고 개선해보는게 책으로 읽는 레슨런보다 더 절절히 와닿는 것 같다.

철저히 우선순위대로 일해야한다

한두시간이면 될것 같은 일을 이전에는 크게 일이라 생각하지 않았다. 팀 내 다른 직군의 분들이 스프린트 외적으로 해야하는 일을 요청하면 팀 내에 백엔드 개발자가 한명 더 계셨을 땐 기꺼이 맡아서 빠르게 처리하곤 했다. 그렇게 해도 스프린트 내에서 해야할 일들을 충분히 할 수 있었다. 근데 팀 내에 백엔드 개발자가 나 혼자가 되었을때 분명 쥐어짜서 달리고 있는데 일이 점점 더 쌓이는 현상이 생겼다. QA하며 발견된 버그, 사업담당자의 쿼리 수정 요청, 스프린트 일감들, 내가 발견하는 기술적 이슈들이 한꺼번에 쌓여있을 때는 ‘야근하면 되지 뭐’가 먹히지 않았다. 내 시간과 에너지는 한정되어있으니까… 🫠 결국 제일 중요한건 스프린트 내의 최소 완료기준을 충족시키는 것이었고, 그 나머지들은 담당자들과 우선순위 및 기한들을 조정했다. 너무 아쉬운데 버리다시피 나중으로 미루게 되는 백로그들도 있었다. 그래도 그렇게 하다보니 지속가능한 상태로 일을 할 수 있었다. 그리고 사실 바쁘지 않을 때에도 그 시기에 내가 무엇을 해야하는지, 팀의 미션 외에 개인적으로도 중요도와 임팩트를 더 생각했어야 했다는 걸 나중에 이력서를 정리하면서 알게됐다.

좋은 사람들을 만나 배운것

‘이상한’ 사람들이 좋다

입사 후 거의 두달동안 낯가리는 상태로 팀원들을 대했던 기억이 난다. 할말을 못하는 수준은 아니었지만, 수습기간인데다 목적조직 구성원이 되고 나니 리더 뿐만 아니라 모두가 나를 평가할 수 있는 사람처럼 보였다. 낯가리는걸 쿨하게(?) 자기 소개 시간에 팀원들에게도 오픈하긴 했었는데 그때의 낯가린다는 표현은 사실상 ‘이상한/못하는 사람으로 평가받을까봐 좀더 조심하고있다’는 뜻이었다.

다행히 팀에는 서로 도와주고 싶어하고, 다 같이 잘해보고 싶어하는 분들로만 구성되어있었다. 다른 팀원을 함부로 판단/평가하거나 의견을 까내리고 자신을 우위에 세우려는 태도를 가진 사람들은 아무도 안계셨다. 일을 해볼수록 팀원들과 점점 더 케미가 잘맞는단걸 확인해갔다. 이 사람들이 누구를 평가하기보다 어떻게든 일을 잘해보려고 노력하고 나도 그 일원이라는 걸 몸소 느껴가며 점차 심리적인 안정감이 생기고 표현에 거리낌이 없어질 수 있었다. 어느 순간부터는 “OO님 진짜 이상한사람ㅋㅋㅋ” 하며 서로 놀리는데 그게 그사람의 개성에 대한 칭찬이 되고 있었다. 원래 사람들은 서로 다르고 특이한 생각들도 하고 나도 그렇다. 근데 그걸 숨기려고 하거나 어떤 보이지않는 틀에 가둬두려고 하지 않고 건강한 방식으로 생각들을 표현할 때 더 제품의 발전에 도움되는 아이디어들도 잘 나오고 팀워크도 좋았던 것 같다.

칭찬은 아낌없이 하자

생각해보면 예전의 나는 조용히 오 저거 괜찮은데. 잘하셨네. 속으로 생각하고 그냥 넘어가는 경우가 많았다. 근데 이번 회사에서 무수한 👍이모지와 직접 만들어주신 이모지와 짤과 각양각색 크고작은 리액션과 칭찬들을 받다보니 이게 얼마나 격려가 되고 회사생활을 재밌게 해주는것인지 알게 됐다. (장난치며 👎이모지가 유행하기도 했지만😊) 어느 순간부터는 나도 ‘최고의기획자’ 같은 이모지를 만들기도 하고 회고 시간에 짧게 적어놓는 등 넘어가기보다 한번 더 표현하게 됐다. 억지로 하는 칭찬 말고, 진짜 잘한다 싶은걸 칭찬하고 격려하고 수고를 인정해주는 문화가 있어서 행복했다.

나 자신에 대한 이해

  • 피드백을 통해 알게된 것

누군가에게 피드백을 해준다는건 그만큼의 관심과 관찰이 있어야 가능한 일이다. 입사 초 상반기 평가를 해야하는 시즌이 왔었는데, 같은 팀 내에서도 업무상 많이 엮여있어 이야기를 많이 하는 팀원들에게는 피드백 주기가 쉬웠지만 그렇지 않은 팀원에게는 무슨 말을 해야할지 당황스러웠다. 그런데 나중에 그분들은 나를 더 관심있게 보시고 평가를 써주셔서 부끄러웠던 기억이 있다. 나는 그냥 ‘잘하고 계신다’ 라고 하면 곧이곧대로 받아들이지 못하고 뭘 잘하는지 캐물어보곤 했는데(리더님들께 죄송..) 그때마다 주신 피드백을 통해 나에 대한 처음듣는 워딩들을 들어보기도 하고, 내가 저평가하고 있는 강점에 대해서 알 수 있었다.

  • 팀원들의 탁월함을 통해 알게된 것

내가 얼마나 얕은 사람이었는지, 부족한 사람인지를 절절히 느끼게된 순간들이 있었다. 많은 문제의식들 중 하나를 분석해서 이니셔티브를 도출하는 과정에서 딥다이브하고 있는 팀원들을 볼 때, 나는 생각도 못해본 기술적인 고민을 공유받을 때 등. 일일이 다 적을 수 없는 닮고싶고 채우고싶은 것들이 있었다. 그때마다 자극받아서 더 찾아보고 고민해보게 되었고 머릿속에 아직도 남아있는 높은 기준들이 있다.


이런 배움을 정리하는 것도 이 회사에 와서 좀더 습관적으로 하게되었던 일인 것 같다. 적고보니 주절주절 배움보다는 나한테 좋았던걸 쓴거같기도 하다..ㅋㅋ 감사하는 마음으로 지금의 여정을 잘 마무리하고, 다음 스텝을 준비해야겠다. 일하는 방식, 추구하는 가치, 팀의 성향 등등 많은 것들이 달라지겠지만 또 어떤 배움이 있을지 기대가 된다.